V.FHIR Server

14 HAPI FHIR 周邊設定(安控,攔截器,負載)，HAPI Validate可能的問題(data lost)

今天的主題也不是我特別擅長的，最近因為工作需求有碰到一些非FHIR的伺服器建置，但其實兩者是殊途同歸的，

在最開始討論HAPI FHIR的時候，提到了HAPI FHIR作為一個開源社群版的應用軟體，以商用的角度來說還有非常多部份需要完成實作或跨接軟體，

如果使用端只是想把FHIR Server做為是一個FHIR Resource的儲存點，那這些可以忽略，但如果要上線的話就必須要考慮周邊協作

除了透過實際更動內部架構實作外，比較容易執行的方式是將服務介接到多個軟體上分別完善功能，，

這個部分又稱為Interceptor，中繼器，可以在需求的輸出入端執行攔截跟代理，為資料交換等提供其他效能或安全上的支援
https://hapifhir.io/hapi-fhir/docs/interceptors/interceptors.html

這部分需要以Java介入實作，有興趣的可以看一下
https://hackmd.io/@hongyu0324/interceptor

首先是安全控制與權限部分，可以選擇

Keycloak: Red Hat公司的開源產品，目前已支援OAuth，可以透過Docker Image compose的方式建置，
透過Keycloak dashboard內的Clients來設定要監聽的URL(HAPI FHIR URL)來實現權限控制

若透過Keycloak作為中繼，在透過REST存取FHIR Server時必須要在Authorization上加上access token，詳細的細節請見keycloak的其他教學。

gluu、Auth0等服務若有興趣再自行研究，僅供參考

效能分配、負載平衡與反向代理: nginx，結合多種優點與輕量化於一身，使用者只需要修改nginx.conf就能整合出nginx所需要提供的服務，

如果是走容器部署，可以直接選擇k8s，筆者目前還沒有布置到使用k8s執行FHIR Server的周邊運作，就先寫到這裡。

在現有project的部分，HAPI FHIR AU有自行實作結合Authorization的方案
實際的文章分享可以看這篇
https://rob-ferguson.me/add-authn-to-hapi-fhir-with-oauth2-proxy-nginx-and-keycloak-part-1/
https://github.com/Robinyo/hapi-fhir-au/?ref=rob-ferguson

這裡要切開來另一個主題來看，前面提到了HAPI FHIR本身是需要多種服務來介接，那HAPI FHIR的運作現階段有沒有什麼比較大的問題

有，仍然是昨天有提到一點的內容，驗證。

根據chinlin的文章與筆者自行測試HAPI的$validate功能，HAPI FHIR執行驗證功能時，如果驗證的資料過大(Bundle,2000+行)有觀測到資料遺失的問題，

這個問題困擾我非常久了，在驗證的部分我後來都是採用DICOM實驗室的驗證器或是HL7的fhir validator，
但原生的validator(後面會講)也有一些問題，在驗證上就出現了非常大的麻煩。

但驗證在FHIR中是很重要的一個部分，我必須要確定我今天持有的FHIR Resource是否是正常合乎IG標準的，否則在上傳資料時會被退件或審查失敗，
目前官方在使用的IG有另一個問題是，更新過於頻繁。

以國際慣例來說，IG的更新時程大約為半年至一年一版，在這段期間內所有關於該IG的傳輸交換都是遵守已發布於FHIR IG Registry的版本，

但以健保署正推行的TWPAS 事前審查IG來說，目前的更新頻次是一個月一個版本，這也就意味著

1. 現行版本並不一定已登錄至國際IG註冊平台

2. 國際IG平台上提供的IG package已deprecated

3. 因HAPI FHIR的data lost問題，透過HAPI FHIR驗證有失敗的風險，無法穩定使用

關於驗證的細節我會放在明天細說，

總而言之，FHIR作為開源免費的FHIR Server選擇，能夠讓使用者很容易架設與使用，但關於商用的功能實現仍有待加強，需要多方整合。

在這篇系列文中，我將FHIR Server的角色視為是FUME的協力者，儲存FUME執行轉換時所需要的資源，

未來若FHIR與FUME兩者需要上線時，仍需要採用完善周邊的方案以確保資料和系統的安全性。

至於驗證這件事情本身也算是個大坑，但是迴避不掉的問題，

明天會來談一談現有的驗證器，以及各自有的問題，總結一下驗證的定義到底是什麼。